This commit adds a progressbar interface and implementations:
1. terminalProgressBar based on github.com/cheggaaa/pb/v3
2. plainProgressBar to just pass the message but no progress
3. debugProgressBar to print the osbuild/images status

The interface is very tailored to the needs of bib but it should
be similar enough to be reusable by `image-builder-cli`.

It contains a top level spinner that gives the current step:
"Make manifest" or "Building image". The the subprogress from
osbuild: the pipelines and the stages from the pipelines as
progress bars and the last line is the latest status message,
usually something from osbuild like "Starting pipeline qcow2".

The spinenr is a bit of a creative choice, it could also be a
progress bar because we know the steps (manifest+build). But the
runtime is totally dominated by the build step so having a first level
progress bar is odd as the UI will spend 90% of the time in it.
Plus the spinner gives it more a more "dynamic" appearnce.

This commit implements enough of `pb.Pool` for our needs
without the need to implement raw terminal access.

It turns out that by default podman does not connect the
full tty, even in `--privileged` mode. This is a sensible
security default but it means `pb.Pool` does not work as
it wants to set the terminal into "raw" mode and will fail
with an ioctl() error when not running on a terminal.

However we really just need simple ANSI sequences to
render the pool so this seems unnecessary. The initial
idea was to just use  `--log-driver=passthrough-tty` but
that is not available on podman 4.x. (which is part of
Ubuntu 24.04 LTS and the GH actions).

So this commit just implemnts a custom pool like renderer.

The Start/Stop methods can no longer error so remove the error
from the signature. The commit also tweaks the doc strings and
comments slightly.

manifestFromCobra generate an osbuild manifest from a cobra
commandline and it also takes a progress.ProgressBar as input.

It needs an unstarted progres bar and will start it at the right
point (it cannot be started yet to avoid the "podman pull" progress
and our progress fighting). The caller is responsible for stopping
the progress bar (this functtion cannot know what else needs to happen
after manifest generation).

TODO: provide a podman progress reader to integrate the podman progress
into our progress.

Thanks to Ondrej for the suggestion to clarify the relationship
further.

This commit adds some extra checks to ensure that the pb.ProgressBar
does not contain any errors. This should not happen but we want
to be paranoid (especially since the error handling of pb.ProgressBar
is a bit indirect).

This commit fixes a bug in the progress rendering when no terminal
width can be identified. In this case pb.ProgressBar will strip
bars with dynamic elements. This is undesirable so when no size
can be found we just use the pb.defaultBarWidth (which is not
exported sadly). This should get fixed upstream ideally.

The upload code is currently using a plain "pb.ProgressBar" and
this is tested as part of our integration test. This will collide
with our own progress implementation. For now workaround this by
stopping our own progress and let plain "pb" takeover.

I was tempted to fix it right away but the PR with the progress
is already relatively big so I opted for a followup.